Последние несколько месяцев слышал от разных людей (у нас и за границей) похожие истории про техдолг:

Не можем получить новую фичу вообще никак. Сроки просраны, а результат не предвидится. Заливание баблом, джунами и индусами больше не работает. Начальство в бешенстве, переписывать нет времени, что делать — не понятно.

В общем, долго клали болт на соответствие потребностей и реализации, и вот вдруг ВНЕЗАПНО что-то пошло не так.

Возможно, это явление массовое и происходит от общепринятого подхода в индустрии: да пофиг ваще, бизнес бабки колотит, остальное похер. В ключевых системах ожидаемо накопилась критическая масса, и техдолг начал стрелять у всех. Ну или это просто совпадение.

Происходит ли у вас что-то подобное? Поделитесь, нам важно это знать :3

К посту про SQL. Пока лазил на сайте Postgres Professional, наткнулся ещё на одну интересную книгу — «Путеводитель по базам данных».

Что внутри:
— Какие структуры данных используются для построения СУБД
— На каких алгоритмах построены распределённые СУБД
— Репликация и бекапы
— Журналирование
— Управление доступом

Для хардкорщиков, сохраняющих петабайты транзакций в наносек, будет не очень интересно, а вот для спецов среднего уровня и выше или для тех, кто хочет систематизировать знания и закрыть пробелы, — самое то.

#полезнота

На следующей неделе планируем провести стрим на тему «Внедрение DDD на практике — профиты и проблемы».

К нам в гости придет наш товарищ Константин Шибков, старший Java разработчик СДЕК, автор курсов и статей по разработке, соорганизатор митапа про бережливые бизнес процессы AgileUfa и клуба разработчиков JavaKeyFrames.

Мы обсудим как Константин внедрял архитектурные подходы и паттерны и узнаем, что из этого вышло.

Ссылку пришлем позже, приходите и задавайте вопросы 🙂

Предварительно, запланировали стрим в четверг 31 октября в 18:00 МСК

Напоминаем, что сегодня состоится встреча. Ссылку скинем перед началом. Не пропустите!

Погнали! https://youtube.com/live/HYI5XzQFE3U?feature=share

Мы не знаем кто автор, но это просто шедеврально

Нас много раз спрашивали как удобнее всего обрабатывать ошибки и исключения. Рассказываем, как мы это делаем и почему стандартный try-catch не всегда удобен.

Если видос показался полезным — поделитесь с братюнями. И подпишитесь на канал, конечно же

Приятного просмотра!

Для тех кто пропустил или не подписан на наши ютубы - выпустили видосик на тему выбора языка и стека. Попробовали собрать в кучу те критерии, которые считаем важными. Для наших постоянных читателей такая тема может и не совсем актуальна, но вдруг кто хочет поменять стек либо же находится в начале пути

⚠️ Осторожно! В комментах местами портал в дурку, посему приглашаем к веселью (вы знаете что делать).

Приятного просмотра!

Инфляция тайтлов: 18-летние синьоры уже реальность
(*пост не ставит целью оскорбить или унизить кого-либо)

И к сожалению эта напасть касается нас всех.

Инфляция тайтлов — это когда компании громко называют обычные должности. У всех, например, уборщица, а у нас — операционный менеджер мануального клининга, в этом духе. Такие должности по названию не соответствуют реальным обязанностям, уровню старшинства, да и заработной плате. Иначе зачем всё это, вообще?

(Продолжение ниже)

В продолжение поста

Громкому тайтлу можно меньше платить

Громкий тайтл может перекрыть разницу в деньгах, так что получать Principal Software Architect & Visionary Technologist может меньше, чем обычный Developer. Ну и ещё это престижно звучит: уезжал из деревни студентом, а вернулся тем, кого и назвать сразу не получается. Почёт и уважение обеспечены, — думает уязвимый к брехне человек и принимает офер.

Громким званием проще сманить. Люди переходят охотнее в новые компании, если им предложить тайтл выше их текущего + небольшая прибавка зарплаты. Жертве кажется, что она много добилась и двигается по карьерной лестнице вверх, а там уже томятся ещё 20+ гибридных позиций, порождённых инфляцией.

И теперь ничего не понятно

Нельзя наверняка сказать, чем занимается Senior Staff Software Engineer. Где как. Одни компании требуют писать код в 2 раза быстрее, чем Senior Developer. Другие ждут на эту позицию динозавра с 15 годами опыта. В общем, пока не допросишь HR, не поймёшь, что скрывается за названием позиции. А увидя должность Associate Vice President, типичный разработчик вообще пройдёт мимо, подумав, что не про него. И совершенно зря.

Только Executive Director не пишет код. Даже Сеньер Вице-Президент код писать должен.

Хотя науке известен случай когда Executive Director перешел на позицию Senior Developer в другую "нормальную" компанию. Даже так случается 🙂

Ещё один способ оценки квалификации

Если вы руководите не только собой, вам рано или поздно потребуется как-то оценивать и называть квалификацию сотрудников. Самая живучая практика — модель Junior/Middle/Senior/Principal/etc. Но, как мы все понимаем, эти слова мало что говорят о человеке:

— В каждой конторе свой уровень сложности проектов, и что для одних Senior, для других — Middle+

— Инструментов много, владеют ими все по-разному. Вполне нормально, когда Senior не владеет чем-то, что на конкретном проекте не нужно.

— Фреймворками дело не ограничивается, есть ещё аналитическое мышление, знания в определённых предметных областях, конструкторские навыки и всякие там софт-скиллы. Короче, тысячи их: некоторые желательны, некоторые необходимы. Например, без навыков анализа хорошим разрабом не станешь.

Квалификацию все описывают в меру фантазии и ресурсов. Обычно получаются широченные таблицы с картами компетенций, которые, по сути, просто описывают подгрейды между базовыми джунами-синьорами.

Мы тоже попробовали, но пошли другим путём, от конкретного человека, а не от абстрактного идеала. Вместо этого мы декомпозировали квалификацию на составляющие и оценили каждую по шестибалльной шкале. Получилось так: пример оценки компетенций сферического Олега.

Выглядит неплохо, правда, чтобы поддерживать такую систему оценки, потребуется целый отдел. Но вы можете воспользоваться шкалой. Например, пройтись по ветке своей специализации на сайте с роадмапами и оценить свои навыки. Это помогает найти пробелы в знаниях и проблемные места.

Наше ретро. Вопрос к читателям: а вы его проводите? ИМХО лучше проблемы фиксировать и решать по мере поступления, а не устраивать сеанс групповой психотерапии на котором все поноют и разойдутся с нулевым результатом

Сергей на связи! Не собеседуйтесь в Индию. Там вы будете конкурировать со специалистами по трудоустройству, которые специализируются на прохождении собеседований.

Недавно разговаривал с индусом, который собеседует разработчиков из Индии и со всего мира. Он предпочитает нанимать иностранцев, хотя они не очень умеют проходить собеседования. Деревья в уме крутят плохо, строку по полчаса переворачивают и в загадках путаются, зато потом нормально работают. 

В Индии же наоборот: все учатся проходить собеседование, а не работать. Количество и качество резюме очень высокое, но по опыту скажу, что всё из индусского резюме можно смело делить на три. Как следствие, требования при наборе в Индии становятся жёстче, чтобы отсеивать Д'артаньянов, которые потом будут SQL-запросы из контроллеров делать. 

Вывод. Очевидно, что прохождение таких собеседований и навык работы — две разные вещи. Корреляции между ними интервьюеры не наблюдают, но и менять стиль собеседования не торопятся, так что реальные навыки у вас никто проверять не будет.

В комментариях к одной из наших заметок упоминали пассажиров. Мол, зачем нам люди, которые просто сидят и машут веслом, как велено. Они же не добавляют команде ценности. Хотелось бы немного развить эту мысль.
Мы выделяем три главных качества: адекватность, исполнительность и обучаемость. Есть и четвёртое — инициативность.

Но эта не такая инициативность, когда чел всех задалбывает идеями, тащит на себя чужие обязанности и веслает по ночам за интересные задачи. Мы о другом, более комплексном, когда человек самостоятелен, последователен и автономен.

Самостоятельность — способность оценить результат своей или не своей работы и улучшить её, не дожидаясь таски. Например, такой человек увидел повторяющуюся проблему, взял — и решил. Или что-то работало на 80%, а он взял — и улучшил до 99%.

Последовательность — доведение дел до логического завершения, хотя бы какого-то из этапов. Необязательно своими руками, но чтоб проследил и убедился, что готово.

Автономность — способность думать и действовать в меру возможностей без надзора и внешнего импульса. Например, между сервисами нет дырки, а человек взял — и завёл заявки, тегнул нужных людей, организовал дырку. А не сидел и жаловался, что никто этого не сделал вместо него.

К сожалению, таких людей хорошо, если 10%. Это не плохо, кому-то нравится просто веслать и в ус не дуть (мы тоже так хотим на самом деле, но не разрешаем сами себе). Но если у вас на проекте одни пассажиры, быть беде. Придётся директивно управлять, решат все проблемы самостоятельно, и вы как руководитель выгорите в угли. Особенно печально, если среди пассажиров окажутся лиды. Такие способны угробить любое начинание.

Так что цените инициативных людей, целуйте их в попку, одаривайте плюшками и двигайте вверх. Даже с нехваткой квалификации они быстро прокачиваются и занимают ключевые позиции.

Как обычно, это субъективное наблюдение меня, Сережи и других коллег, а поэтому не истина в последней инстанции. Можно приходить в комментарии и накидывать.